1. Technical Field
The present invention relates generally to monitoring software performance, and specifically to selective monitoring of individual transactions in an instrumented software application.
2. Description of Related Art
One key task in system administration is to monitor the performance and availability of software applications, including those that may spread across multiple physical systems involving multiple physical resources. Typically, this monitoring is performed by instrumenting the software to include additional instructions, called “probes,” to report performance information, such as application response time. Performance monitoring may also be implemented in an enterprise by adding an additional software component, sometimes called a plug-in, to the application that is invoked inline during the execution of the transaction. Since the monitoring is performed in real-time, any such monitoring causes some degree of run-time performance overhead on the monitored systems. Thus, it is important to provide a control mechanism to configure the monitoring activity at an adequate granularity.
Existing approaches include selectively turning the monitoring on or off based on the application or logic component. For example, when a user initiates a transaction from a Web browser, the request is sent to a Web server, which in turn makes a call to an application server and a database server. The request is then translated into database access operations. Traditionally, if the user experienced a performance problem, the entire application that runs on the Web server, the application server, and the database server would be monitored in order to pinpoint the root cause of the problem. However, there are two major drawbacks to this methodology.
First, when transaction monitoring is enabled for an application, all business transactions in that application are monitored, regardless of whether or not they are relevant to identify the performance problem. This incurs more overhead in terms of CPU usage, memory, etc. than necessary to solve the problem.
Second, when transaction monitoring is enabled for an application, every transaction in the application will generate additional monitoring information at the same level. The accumulated data volume can become very high within a short period of time, thus incurring additional overhead to process the data. The high data volume can also obscure the root cause of the problem in that there is a large quantity of irrelevant data for the user to review and ultimately ignore.
Hence, the inventors have recognized the state of the art would be improved by a refined way to monitor applications that avoids or reduces the overhead cost of monitoring.